1. Field of the Invention
The present invention relates to a computer program and method for supporting implementation of business-specific service functions on a computer system. More particularly, the present invention relates to a computer program and method for supporting implementation of service functions on a computer system formed from a plurality of servers.
2. Description of the Related Art
Service Oriented Architecture (SOA) has been of great interest as a methodology for developing business applications. SOA enables a business system to be built as an organized set of reasonably divided business functions, called “services,” designed to work together in a cooperative fashion. SOA-based development of a computer system for a specific business purpose begins with describing an overall flow of business activities in a script called a “business process model.” The second step is to produce execution flows from that business process model. Execution flows describe in detail what part of processing functions the servers are supposed to provide. The third step is to deploy those execution flows on their corresponding servers, so that the servers will provide intended services according to the execution flows.
Researchers have proposed various techniques for automatically creating execution flows from a given business process model. See, for example, Japanese Patent Application Publication No. 2001-92647. This publication discloses a technique for generating multi-thread parallel processing programs from a business process script defining a specific business process. However, a difficulty arises when one applies the proposed technique in implementing a business application on a network of multiple servers. While servers in such a system have to cooperate together, it is not easy to generate cooperative execution flows automatically from a business process model.
One reason for the difficulty in creating execution flows for a distributed system is that those who build a business process model do not have sufficient knowledge about actual deployment of execution flows in a target system. In other words, process model designers may not always know necessary techniques for system integration. And this lack of knowledge on the part of process designers makes automated service implementation difficult. More specifically, the above-described difficulty comes from the following three gaps between process modeling and execution flow generation:
The first gap lies in the difference in their viewpoints on the system. Generally a business process model is built from a third-party viewpoint, independent of any particular system component. Execution flows, on the other hand, view a system from a more specific viewpoint since they have to describe specific functions that each service provider (i.e., server) is supposed to offer, including how to invoke other related services. In other words, the execution flow generator needs to have more explicit information about each pair of cooperative services. The lack of this information makes it difficult to-generate execution flows automatically from a business process model.
The second gap lies in the awareness (or lack thereof) of interactions between services. A business process model describes a sequence of activities without explicitly specifying how the system components are supposed to interact. Execution flows, on the other hand, need to be specific enough in terms of the interface between services and the way of messaging (i.e., synchronous or asynchronous).
The third gap lies in the way of handling asynchronous services. Asynchronous communication between services may not necessarily be apparent in a business process model because it only describes a process flow in a sequential manner. Execution flows may, on the other hand, vary depending on whether the services use synchronous messaging or asynchronous messaging for their interaction, since they have to define how requests and responses are communicated between each pair of services, as well as offering an interface for receiving return values.
Because of the above-described gaps in system design approach, the execution flows produced by a conventional method may not be satisfactory in terms of stability and efficiency of processing, thus failing to provide an optimal system design. While some system integration techniques based on workflow technology (e.g., Enterprise Application Integration (EAI)) have been available, most workflow-based business applications lack the ability of sharing their components with other applications.
Flow definition languages such as Business Process Execution Language (BPEL) enable existing web services to cooperate together, typically by allowing a service to invoke other necessary services. However, it is necessary, in this approach, for each implemented service to have an explicit definition of what functions to delegate and which services to invoke in performing that delegation. The amount of services deployed on each server, as well as selection of service combinations, has to be fine-tuned manually, depending on whether the entire system is managed by a flow engine or by Remote Procedure Call (RPC) facilities.